.NET uses the Strong Name tool, sn.exe, to help authenticate assemblies. (For those of you playing the Linux home game, a .NET assembly is a self-describing shared object library, like a .so for object libraries.) sn.exe signs the assembly with the secret key of a public key cryptography pair, then embeds the public key of the pair in the assembly. This lets you verify the integrity of the assembly by verifying that the contents of the file were signed with the embedded key.
What good is this? Not as much as you would hope. Since you don't know for sure where the public key came from (as it just came with the assembly), it could be that some dastardly person has modified the assembly, substituting their own public key for the original public key. Without some out-of-band knowledge about where this key came from, you cannot know whether the public key in the assembly is from the original author or Mallet (the canonical bad guy in cryptography literature).
Using sn.exe protects against simple modification attacks – attacks where the signature is compromised – but does not help prevent attacks where both the assembly code and the assembly signing key is compromised. This is in contrast to cryptographic systems like PGP/GPG and Entrust, where you have some assurances that the public key you use is actually from who you think it is from, due to the use of keyservers. When you are certain that a public key belongs to who you think it does, you can then assume that the signed object was signed by who you thought it was signed by. Unfortunately, sn.exe can give you no such assurances.
The lesson we can take away from this is that (for now) sn.exe protects against script kiddie attacks, but does not protect against attacks by the more sophisticated malefactors.
